server/utils/schemas/trackingLink.ts (1)

69-76: Consider extracting shared UTM field definitions to reduce duplication.

The UTM fields (utmSource, utmMedium, utmCampaign, utmTerm, utmContent) are duplicated across createTrackingLinkSchema, updateTrackingLinkSchema, and applicationSourceSchema. Extracting a shared partial schema would improve maintainability.

♻️ Proposed refactor to reduce duplication

+/** Shared UTM field definitions */
+const utmFieldsSchema = z.object({
+  utmSource: z.string().max(200).optional(),
+  utmMedium: z.string().max(200).optional(),
+  utmCampaign: z.string().max(200).optional(),
+  utmTerm: z.string().max(200).optional(),
+  utmContent: z.string().max(200).optional(),
+})
+
 /** Schema for creating a tracking link */
 export const createTrackingLinkSchema = z.object({
   jobId: z.string().min(1).optional(),
   channel: sourceChannelSchema.default('custom'),
   name: z.string().min(1, 'Name is required').max(200),
-  utmSource: z.string().max(200).optional(),
-  utmMedium: z.string().max(200).optional(),
-  utmCampaign: z.string().max(200).optional(),
-  utmTerm: z.string().max(200).optional(),
-  utmContent: z.string().max(200).optional(),
-})
+}).merge(utmFieldsSchema)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/utils/schemas/trackingLink.ts` around lines 69 - 76, The UTM fields
are duplicated across createTrackingLinkSchema, updateTrackingLinkSchema, and
applicationSourceSchema; create a shared Zod partial (e.g., utmFieldsSchema =
z.object({ utmSource: z.string().max(200).optional(), utmMedium:
z.string().max(200).optional(), utmCampaign: z.string().max(200).optional(),
utmTerm: z.string().max(200).optional(), utmContent:
z.string().max(200).optional() })) and replace the repeated field definitions by
merging or extending that partial into applicationSourceSchema and into the
definitions used by createTrackingLinkSchema and updateTrackingLinkSchema (use
.merge() or spread with .extend() as appropriate) so all three schemas reference
the single utmFieldsSchema.

server/api/tracking-links/index.get.ts (1)

1-1: Remove unused import.

The sql import from drizzle-orm is not used in this file.

🧹 Proposed fix

-import { eq, and, desc, sql } from 'drizzle-orm'
+import { eq, and, desc } from 'drizzle-orm'

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/tracking-links/index.get.ts` at line 1, The import list in
server/api/tracking-links/index.get.ts includes an unused symbol `sql` from
'drizzle-orm'; remove `sql` from the import statement (leave `eq`, `and`,
`desc`) to clean up unused imports and avoid lint warnings, updating the import
that currently reads like "import { eq, and, desc, sql } from 'drizzle-orm'".

server/api/public/jobs/[slug]/apply.post.ts (1)

740-743: Minor: Redundant exact-match check in suffix matching loop.

Line 740 already handles exact matches (if (mapping[d])), so the d === key check in line 742 will never be true.

🧹 Proposed simplification

   // Check for exact match first, then suffix match for subdomains
   if (mapping[d]) return mapping[d]!
   for (const [key, channel] of Object.entries(mapping)) {
-    if (d.endsWith(`.${key}`) || d === key) return channel
+    if (d.endsWith(`.${key}`)) return channel
   }
   return null

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/public/jobs/`[slug]/apply.post.ts around lines 740 - 743, The loop
that finds a channel for a domain redundantly checks exact equality (d === key)
even though the exact match is already handled by the earlier if (mapping[d])
return mapping[d]!, so update the loop in the domain-to-channel lookup to only
test suffix matches (i.e., remove the d === key branch) by changing the for
(const [key, channel] of Object.entries(mapping)) { if (d.endsWith(`.${key}`))
return channel } so exact matches remain handled by mapping[d] and the loop only
handles subdomain suffixes.

server/api/source-tracking/stats.get.ts (2)

37-159: Consider adding a composite index for performance.

The 8 concurrent queries all filter by organization_id with optional created_at date ranges. The existing indexes (per context snippet 3) don't include a composite (organization_id, created_at) index on applicationSource, which would significantly improve query performance for date-filtered analytics.

Consider adding a migration with:

CREATE INDEX "application_source_org_created_idx" ON "application_source" USING btree ("organization_id", "created_at");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/source-tracking/stats.get.ts` around lines 37 - 159, The queries
against applicationSource (used in the Promise.all block: channelBreakdown,
dailyTrend, recentAttributed, topReferrerDomains, and the total
tracked/untracked calculations) filter by organizationId and createdAt and need
a composite index to speed date-filtered analytics; add a new DB migration that
creates a btree composite index on (organization_id, created_at) for the
application_source table (suggest a name like
application_source_org_created_idx), run/verify the migration, and update any
migration manifests so production/db CI applies it.

---

134-142: Type the raw SQL query result.

Using any for the query result bypasses type checking.

🧹 Proposed fix

     // 7. Total untracked applications (no source record)
-    db.execute(sql`
+    db.execute<{ count: string }>(sql`
       SELECT count(*) as count
       FROM ${application} a
       WHERE a.organization_id = ${orgId}
         AND NOT EXISTS (
           SELECT 1 FROM ${applicationSource} s
           WHERE s.application_id = a.id
         )
-    `).then((r: any) => Number(r[0]?.count ?? 0)),
+    `).then((r) => Number(r.rows[0]?.count ?? 0)),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/source-tracking/stats.get.ts` around lines 134 - 142, The query
result is typed as any which bypasses type checking; update the db.execute call
for the COUNT query so it returns a typed array of rows (e.g., db.execute<{
count: number }[]>(sql`...`)) and then use that typed result in the mapping
(replace the (r: any) parameter with a correctly typed parameter) so
Number(r[0]?.count ?? 0) is type-safe; target the db.execute(sql`...`)
invocation in stats.get.ts to implement this change.

server/api/public/track/[code].get.ts (1)

38-44: Consider URL encoding the code parameter.

The code is appended directly to the query string without encoding. While the code is base64url (URL-safe), if future code generation changes or if malformed codes reach this point, it could cause issues.

🛡️ Proposed fix

   const baseUrl = env.BETTER_AUTH_URL || `https://${getHeader(event, 'host')}`
   const targetPath = link.job?.slug
-    ? `/jobs/${link.job.slug}/apply?ref=${code}`
-    : `/jobs?ref=${code}`
+    ? `/jobs/${link.job.slug}/apply?ref=${encodeURIComponent(code)}`
+    : `/jobs?ref=${encodeURIComponent(code)}`

   return sendRedirect(event, `${baseUrl}${targetPath}`, 302)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/public/track/`[code].get.ts around lines 38 - 44, The redirect
builds targetPath using the raw code and appends it to the query string, which
can break if code contains unsafe characters; update the construction of the
targetPath (used before calling sendRedirect) to URL-encode the code (e.g., via
encodeURIComponent) so the value of code is safely included in the query param;
ensure you update the expression that references code (where targetPath is
computed) so sendRedirect(event, `${baseUrl}${targetPath}`, 302) receives a path
with the encoded code.

server/api/tracking-links/index.post.ts (1)

48-54: Consider handling code collision on insert.

The generated code has 48 bits of entropy, making collisions unlikely but possible at scale. The database has a UNIQUE constraint on code, so a collision will cause a 500 error rather than a graceful retry.

For robustness, consider adding retry logic or using ON CONFLICT DO NOTHING with a fallback.

🔄 Proposed fix with retry logic

+const MAX_CODE_RETRIES = 3
+
 export default defineEventHandler(async (event) => {
   const session = await requirePermission(event, { sourceTracking: ['create'] })
   const orgId = session.session.activeOrganizationId
   const userId = session.user.id

   const body = await readValidatedBody(event, createTrackingLinkSchema.parse)

   // If scoped to a job, verify the job belongs to this org
   if (body.jobId) {
     const existingJob = await db.query.job.findFirst({
       where: and(eq(job.id, body.jobId), eq(job.organizationId, orgId)),
       columns: { id: true },
     })
     if (!existingJob) {
       throw createError({ statusCode: 404, statusMessage: 'Job not found' })
     }
   }

-  // Generate a unique short code (8 chars, URL-safe)
-  const code = generateTrackingCode()
-
-  const [created] = await db.insert(trackingLink).values({
-    organizationId: orgId,
-    jobId: body.jobId ?? null,
-    channel: body.channel,
-    name: body.name,
-    code,
-    utmSource: body.utmSource ?? null,
-    utmMedium: body.utmMedium ?? null,
-    utmCampaign: body.utmCampaign ?? null,
-    utmTerm: body.utmTerm ?? null,
-    utmContent: body.utmContent ?? null,
-    createdById: userId,
-  }).returning()
+  // Generate a unique short code with retry on collision
+  let created
+  for (let attempt = 0; attempt < MAX_CODE_RETRIES; attempt++) {
+    const code = generateTrackingCode()
+    try {
+      const [result] = await db.insert(trackingLink).values({
+        organizationId: orgId,
+        jobId: body.jobId ?? null,
+        channel: body.channel,
+        name: body.name,
+        code,
+        utmSource: body.utmSource ?? null,
+        utmMedium: body.utmMedium ?? null,
+        utmCampaign: body.utmCampaign ?? null,
+        utmTerm: body.utmTerm ?? null,
+        utmContent: body.utmContent ?? null,
+        createdById: userId,
+      }).returning()
+      created = result
+      break
+    } catch (err: any) {
+      // Retry only on unique constraint violation
+      if (err?.code !== '23505' || attempt === MAX_CODE_RETRIES - 1) {
+        throw err
+      }
+    }
+  }

   setResponseStatus(event, 201)
   return created
 })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/tracking-links/index.post.ts` around lines 48 - 54, The
generateTrackingCode function can produce collisions; update the POST insert
flow to handle UNIQUE constraint violations by retrying: wrap the insert that
uses generateTrackingCode in a bounded retry loop (e.g., 3–5 attempts),
generating a new code each attempt and breaking on success, and if your DB
client supports it prefer an idempotent pattern like INSERT ... ON CONFLICT DO
NOTHING followed by a SELECT/RETRY if no row was created; specifically catch the
unique-constraint error from your DB client and only retry on that error
(otherwise surface other errors). Ensure you reference generateTrackingCode when
regenerating codes and put limits so you return a 500 or a clear error after
retries are exhausted.

server/database/migrations/0018_source_tracking.sql (1)

44-48: Add an org+created_at index for the stats queries.

The new dashboard filters attribution by organization and date window, but this migration only adds single-column indexes. application_source (organization_id, created_at) will keep those range scans from degrading as the table grows.

Suggested fix

 CREATE INDEX "application_source_organization_id_idx" ON "application_source" USING btree ("organization_id");--> statement-breakpoint
+CREATE INDEX "application_source_organization_created_at_idx" ON "application_source" USING btree ("organization_id", "created_at" DESC);--> statement-breakpoint
 CREATE INDEX "application_source_application_id_idx" ON "application_source" USING btree ("application_id");--> statement-breakpoint

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/database/migrations/0018_source_tracking.sql` around lines 44 - 48,
Add a composite btree index on application_source for (organization_id,
created_at) to support org+date range queries used by the dashboard;
specifically add a statement creating index
"application_source_organization_created_at_idx" ON "application_source" USING
btree ("organization_id", "created_at") alongside the existing single-column
indexes so stats queries avoid full scans as the table grows.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/pages/dashboard/source-tracking.vue (5)

74-78: ⚠️ Potential issue | 🟠 Major

Remove the hard cap of 100 jobs from selector data.

This still truncates job choices for orgs with >100 jobs, which breaks both filtering and create-link scoping.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking.vue` around lines 74 - 78, The useFetch
call for jobs in source-tracking.vue is hard-capped by query: { limit: 100 }
which truncates organizations with more than 100 jobs; remove the limit
parameter from the options passed to useFetch (the const { data: jobsData } =
useFetch('/api/jobs', { key: 'source-tracking-jobs', headers:
useRequestHeaders(['cookie']), query: { limit: 100 }, }) call) so the full job
list is returned (or pass a server-respected parameter like page/offset if you
intend to paginate instead), and verify downstream code that consumes jobsData
(selector, filtering, create-link scoping) still works with the full dataset.

---

1020-1027: ⚠️ Potential issue | 🟡 Minor

Include all supported channels in the create form options.

lever and greenhouse_board are still missing from selectable create options.

Suggested patch

-                  <option v-for="ch in ['linkedin', 'indeed', 'glassdoor', 'ziprecruiter', 'monster', 'handshake', 'angellist', 'wellfound', 'dice', 'stackoverflow', 'weworkremotely', 'remoteok', 'builtin', 'hired', 'google_jobs']" :key="ch" :value="ch">{{ getChannelLabel(ch) }}</option>
+                  <option v-for="ch in ['linkedin', 'indeed', 'glassdoor', 'ziprecruiter', 'monster', 'handshake', 'angellist', 'wellfound', 'dice', 'stackoverflow', 'weworkremotely', 'remoteok', 'builtin', 'hired', 'lever', 'greenhouse_board', 'google_jobs']" :key="ch" :value="ch">{{ getChannelLabel(ch) }}</option>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking.vue` around lines 1020 - 1027, The create
form's channel <option> lists are missing "lever" and "greenhouse_board"; update
the v-for arrays used for the optgroup options (the arrays feeding the v-for in
the template where getChannelLabel(ch) is used) to include "lever" and
"greenhouse_board" in the appropriate groups so those channels become selectable
in the create form (ensure the strings are added to the same arrays referenced
by the v-for and that getChannelLabel can resolve their labels).

---

765-787: ⚠️ Potential issue | 🟡 Minor

Gate the links empty state on linksStatus, not only links.length.

The UI can still flash “Create Your First Tracking Link” while links are loading.

Suggested patch

-        <div v-if="links.length === 0" class="flex flex-col items-center justify-center py-20">
+        <div v-if="linksStatus === 'pending'" class="flex items-center justify-center py-20 text-sm text-surface-500 dark:text-surface-400">
+          Loading tracking links...
+        </div>
+        <div v-else-if="links.length === 0" class="flex flex-col items-center justify-center py-20">
           <div class="rounded-3xl border border-surface-200 dark:border-surface-800 bg-white dark:bg-surface-900 p-14 text-center max-w-md shadow-sm">
             ...
           </div>
         </div>

-        <div v-else class="rounded-2xl border border-surface-200/80 dark:border-surface-800 bg-white dark:bg-surface-900 overflow-hidden shadow-xs dark:shadow-none">
+        <div v-else class="rounded-2xl border border-surface-200/80 dark:border-surface-800 bg-white dark:bg-surface-900 overflow-hidden shadow-xs dark:shadow-none">

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking.vue` around lines 765 - 787, The
empty-state render is only gated by links.length which lets the "Create Your
First Tracking Link" UI flash while data is loading; update the v-if condition
on the empty-state container to also check the load status (use the existing
linksStatus variable) so the empty state only shows when links are empty AND
linksStatus is not loading (e.g. change v-if="links.length === 0" to
v-if="links.length === 0 && linksStatus !== 'loading'" or to an explicit
success/idle status), leaving the existing v-else block intact and keeping the
canManageLinks and showCreateModal bindings as-is.

---

982-1086: ⚠️ Potential issue | 🟠 Major

Both modals still need proper dialog semantics and keyboard/focus behavior.

They still lack dialog roles/labels and robust keyboard/focus management (Escape + trap + restore focus).

Suggested patch (semantics + Escape baseline)

-      <div v-if="showCreateModal" class="fixed inset-0 z-50 flex items-center justify-center p-4">
+      <div
+        v-if="showCreateModal"
+        class="fixed inset-0 z-50 flex items-center justify-center p-4"
+        role="dialog"
+        aria-modal="true"
+        aria-labelledby="create-tracking-link-title"
+        `@keydown.esc.window`="showCreateModal = false"
+      >
...
-            <h2 class="text-base font-semibold text-surface-900 dark:text-surface-100">Create Tracking Link</h2>
+            <h2 id="create-tracking-link-title" class="text-base font-semibold text-surface-900 dark:text-surface-100">Create Tracking Link</h2>
             <button
               class="p-1.5 rounded-lg text-surface-400 hover:text-surface-600 dark:hover:text-surface-200 hover:bg-surface-100 dark:hover:bg-surface-800 transition-colors"
+              aria-label="Close create tracking link dialog"
               `@click`="showCreateModal = false"
             >
...
-      <div v-if="showDeleteConfirm" class="fixed inset-0 z-50 flex items-center justify-center p-4">
+      <div
+        v-if="showDeleteConfirm"
+        class="fixed inset-0 z-50 flex items-center justify-center p-4"
+        role="dialog"
+        aria-modal="true"
+        aria-labelledby="delete-tracking-link-title"
+        `@keydown.esc.window`="showDeleteConfirm = false"
+      >
...
-          <h3 class="text-base font-semibold text-surface-900 dark:text-surface-100 mb-2">Delete Tracking Link?</h3>
+          <h3 id="delete-tracking-link-title" class="text-base font-semibold text-surface-900 dark:text-surface-100 mb-2">Delete Tracking Link?</h3>

Also applies to: 1091-1118

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking.vue` around lines 982 - 1086, The modal
Teleport block that uses showCreateModal (around the Create Tracking Link form
and submit handler handleCreateLink) lacks dialog semantics and keyboard/focus
behavior; add role="dialog" and aria-modal="true" on the modal container and
aria-labelledby pointing to the header H2 (give the H2 a stable id), implement
Escape handling to set showCreateModal = false, implement a focus trap when
showCreateModal is true (move tab focus inside the dialog) and set initial focus
to the first input (link-name) while saving and restoring the previously focused
element when the dialog closes; apply the same changes to the other modal block
referenced (lines 1091-1118) so both modals share consistent semantics and
restore focus on close.

---

853-879: ⚠️ Potential issue | 🟠 Major

Make row actions discoverable without hover.

These controls are still hover-only; touch users and keyboard users get poor discoverability.

Suggested patch

-                    <div class="inline-flex items-center gap-1 opacity-0 group-hover:opacity-100 transition-opacity">
+                    <div class="inline-flex items-center gap-1 opacity-100 sm:opacity-0 sm:group-hover:opacity-100 sm:group-focus-within:opacity-100 pointer-events-auto sm:pointer-events-none sm:group-hover:pointer-events-auto sm:group-focus-within:pointer-events-auto transition-opacity">

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking.vue` around lines 853 - 879, The row
action buttons are hidden via "opacity-0 group-hover:opacity-100", which
prevents touch and keyboard users from discovering them; update the container
div (currently using copiedCode/canManageLinks, and handlers copyTrackingUrl,
toggleLink, confirmDelete) to make controls visible and focusable by replacing
the hover-only classes with something like a low default opacity plus
hover/focus/focus-within rules (e.g., use "opacity-60 hover:opacity-100
focus-within:opacity-100 focus-visible:opacity-100" or similar) so buttons are
always perceivable on touch and keyboard, while keeping hover/focus styles for
emphasis. Ensure you do not remove the buttons themselves (Copy, CheckCircle2,
ToggleRight/Left, Trash2) and that existing `@click` handlers and v-if conditions
remain unchanged.

app/pages/dashboard/jobs/new.vue (1)

374-394: Missing error handling for malformed API response.

If the /api/tracking-links endpoint returns an unexpected shape (missing code or id), the code will silently fail or produce incorrect URLs. Consider adding validation.

💡 Add response validation

 async function createChannelLink(channel: string, channelName: string) {
   if (createdLinks.value[channel]?.code) return
   createdLinks.value[channel] = { code: '', url: '', loading: true, copied: false }
   try {
     const result = await $fetch<{ id: string; code: string }>('/api/tracking-links', {
       method: 'POST',
       body: {
         jobId: createdJobId.value,
         channel,
         name: `${form.value.title} — ${channelName}`,
       },
     })
+    if (!result?.code) {
+      throw new Error('Invalid response: missing tracking code')
+    }
     const base = `${requestUrl.protocol}//${requestUrl.host}`
     const trackUrl = `${base}/api/public/track/${encodeURIComponent(result.code)}`

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/jobs/new.vue` around lines 374 - 394, The
createChannelLink function assumes $fetch('/api/tracking-links') returns {id,
code} but doesn't validate the response shape; add explicit validation after the
fetch to ensure result && typeof result.code === 'string' && typeof result.id
=== 'string' (or at least result.code exists) and throw or go to the catch path
if invalid, so you don't build an incorrect trackUrl or set createdLinks with
empty/invalid values; ensure createdLinks.value[channel] is deleted or updated
to loading:false and toast.error is shown when validation fails, and include a
safe guard before using result.code to build trackUrl and calling
track('tracking_link_created').

e2e/critical-flows/source-tracking.spec.ts (1)

130-133: postDataJSON() assumes JSON body, which may fail for multipart submissions.

If the apply form submits with multipart/form-data (e.g., when a resume is uploaded), postDataJSON() will fail. Since this test disables resume requirement, it should work, but the assumption is fragile if test setup changes.

Consider adding a defensive check or documenting this assumption.

💡 Add defensive handling for request body type

     // Verify the POST body included the tracking params
-    const requestBody = applyResponse.request().postDataJSON()
-    expect(requestBody.ref, 'POST body must include ref code').toBe(REF_CODE)
-    expect(requestBody.utmSource, 'POST body must include utmSource').toBe(UTM_SOURCE)
+    const contentType = applyResponse.request().headers()['content-type'] ?? ''
+    if (contentType.includes('application/json')) {
+      const requestBody = applyResponse.request().postDataJSON()
+      expect(requestBody.ref, 'POST body must include ref code').toBe(REF_CODE)
+      expect(requestBody.utmSource, 'POST body must include utmSource').toBe(UTM_SOURCE)
+    } else {
+      // Multipart form — verify via postData() string contains the values
+      const postData = applyResponse.request().postData() ?? ''
+      expect(postData, 'POST body must include ref code').toContain(REF_CODE)
+      expect(postData, 'POST body must include utmSource').toContain(UTM_SOURCE)
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@e2e/critical-flows/source-tracking.spec.ts` around lines 130 - 133, The test
assumes JSON by calling applyResponse.request().postDataJSON(), which will throw
for multipart/form-data; update the assertion to first inspect the request
content type (via applyResponse.request().headers()['content-type'] or raw
applyResponse.request().postData()), then: if content-type includes
'application/json' call postDataJSON() and assert requestBody.ref/utmSource,
otherwise parse the raw postData() payload (use URLSearchParams for
x-www-form-urlencoded or extract field boundaries/key-values for
multipart/form-data) and assert the ref and utmSource values; alternatively wrap
postDataJSON() in try/catch and fall back to parsing postData() so the test
remains resilient if the form encoding changes.

server/api/public/jobs/[slug]/apply.post.ts (1)

669-707: Consider returning 'other' for unknown UTM sources instead of null.

When mapUtmToChannel receives an unrecognized utm_source, it returns null, which cascades to the referrer check and potentially falls back to 'direct'. However, if a UTM source is explicitly provided but unrecognized, 'other' (which exists in the enum per context snippet 2) might be more semantically accurate than eventually defaulting to 'direct'.

This is minor since the current fallback chain works correctly, but could improve attribution accuracy.

💡 Optional enhancement

   }
-  return mapping[source] ?? null
+  return mapping[source] ?? 'other'
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@server/api/public/jobs/`[slug]/apply.post.ts around lines 669 - 707, The
function mapUtmToChannel currently returns null for unknown but present
utm_source values; change its behavior so that when utmSource is undefined it
still returns null, but when utmSource is provided and not found in the mapping
it returns the semantic fallback 'other' (instead of null) so attribution
doesn't collapse to 'direct'; update mapUtmToChannel to use mapping[source] ??
'other' while keeping the initial if (!utmSource) return null check and
reference the function name mapUtmToChannel and the mapping constant in your
change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/pages/jobs/[slug]/index.vue (1)

12-22: Harden query parameter normalization to handle arrays from repeated params.

On lines 15–20, route.query.* as string assertions can mask array or null values from Vue Router's query parsing. When a URL contains repeated parameters (e.g., ?ref=a&ref=b), route.query returns arrays, and the unsafe cast produces malformed values forwarded to the apply page.

🔧 Suggested hardening

 const applyQuery = computed(() => {
+  const firstQueryValue = (value: unknown): string | undefined => {
+    if (Array.isArray(value)) return typeof value[0] === 'string' ? value[0] : undefined
+    return typeof value === 'string' ? value : undefined
+  }
+
   const q: Record<string, string> = {}
-  if (route.query.ref) q.ref = route.query.ref as string
-  if (route.query.utm_source) q.utm_source = route.query.utm_source as string
-  if (route.query.utm_medium) q.utm_medium = route.query.utm_medium as string
-  if (route.query.utm_campaign) q.utm_campaign = route.query.utm_campaign as string
-  if (route.query.utm_term) q.utm_term = route.query.utm_term as string
-  if (route.query.utm_content) q.utm_content = route.query.utm_content as string
+  const ref = firstQueryValue(route.query.ref)
+  const utmSource = firstQueryValue(route.query.utm_source)
+  const utmMedium = firstQueryValue(route.query.utm_medium)
+  const utmCampaign = firstQueryValue(route.query.utm_campaign)
+  const utmTerm = firstQueryValue(route.query.utm_term)
+  const utmContent = firstQueryValue(route.query.utm_content)
+
+  if (ref) q.ref = ref
+  if (utmSource) q.utm_source = utmSource
+  if (utmMedium) q.utm_medium = utmMedium
+  if (utmCampaign) q.utm_campaign = utmCampaign
+  if (utmTerm) q.utm_term = utmTerm
+  if (utmContent) q.utm_content = utmContent
   return q
 })

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/jobs/`[slug]/index.vue around lines 12 - 22, The computed
applyQuery currently casts route.query.* values to string which breaks when
query params are arrays; update the applyQuery computed function to normalize
each parameter from route.query by checking Array.isArray(route.query.<param>)
and using the first element (or fallback to empty string/undefined) or by
coercing non-string values to string only after this check, ensuring
route.query.ref, utm_source, utm_medium, utm_campaign, utm_term, and utm_content
are safely extracted from arrays/nulls before assigning into the returned q
object; reference the applyQuery computed and route.query usage to locate and
change the normalization logic.

app/pages/dashboard/source-tracking/index.vue (4)

63-72: ⚠️ Potential issue | 🟡 Minor

Wait for linksStatus before rendering link counts or the empty state.

Line 66 already gives you linksStatus, but the Active Links KPI and the “Create Your First Tracking Link” branch still treat an unresolved links request as 0. That briefly shows the wrong count and empty state for orgs that already have links, and it makes fetch failures look like “no data”.

Also applies to: 454-466, 781-802

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking/index.vue` around lines 63 - 72, The
Active Links KPI and the "Create Your First Tracking Link" empty-state are
rendering counts/empty when links are still loading; update the UI to wait for
linksStatus (from useTrackingLinks) to reflect a settled fetch before using
links or totalLinks—e.g., only show the numeric KPI or the "no links" branch
when linksStatus === 'success' (or not 'loading'), otherwise render a
loading/skeleton state or nothing; apply this guard to all places reading
links/totalLinks (the KPI component and the create-first-link branch, plus the
other occurrences referenced) so unresolved or errored fetches don't render as
zero/empty.

---

75-79: ⚠️ Potential issue | 🟠 Major

Don’t cap the job selectors at the first 100 jobs.

This query feeds both the page-level job filter and the “Scope to Job” selector in the create-link modal. Orgs with more than 100 jobs lose the ability to filter analytics or scope a new link to the omitted jobs. Either remove the fixed cap or page/load more here.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking/index.vue` around lines 75 - 79, The
query fetching jobs uses useFetch('/api/jobs', { key: 'source-tracking-jobs',
headers: useRequestHeaders(['cookie']), query: { limit: 100 } }) which
artificially caps results at 100; remove the fixed query.limit or replace it
with a pagination/loading strategy so the page-level job filter and the "Scope
to Job" selector see all jobs (e.g., remove query.limit or implement incremental
loading with page/offset params and a "load more" or fetch-all option in the
component that uses the 'source-tracking-jobs' data).

---

820-901: ⚠️ Potential issue | 🟠 Major

Keep row actions discoverable without hover.

These buttons only appear on group-hover. Touch users never hover, and keyboard users can tab onto fully transparent controls. Make them visible by default on small screens and reveal them on group-focus-within as well.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking/index.vue` around lines 820 - 901, The
action buttons container currently uses "opacity-0 group-hover:opacity-100"
which hides controls for touch and keyboard users; update the div with class
"inline-flex items-center gap-1 opacity-0 group-hover:opacity-100
transition-opacity" to make actions visible by default on small screens and also
reveal on group-focus-within: replace its classes with something like
"inline-flex items-center gap-1 opacity-100 sm:opacity-0 group-hover:opacity-100
group-focus-within:opacity-100 transition-opacity" so mobile users see buttons
and keyboard users see them when the row receives focus; verify this change for
the div that contains the Copy/Toggle/Delete buttons (associated with
copiedCode, copyTrackingUrl, toggleLink, confirmDelete and canManageLinks).

---

1019-1123: ⚠️ Potential issue | 🟠 Major

Both teleported overlays still need real modal accessibility.

The create and delete dialogs are still plain divs: no role="dialog"/aria-modal, no labelled dialog title, no initial focus or focus trap, and no Escape handling. That leaves focus behind the overlay and gives screen readers no dialog context.

Also applies to: 1128-1155

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/source-tracking/index.vue` around lines 1019 - 1123, The
create (Teleport using showCreateModal, form with handleCreateLink, title h2 and
input id="link-name") and delete dialogs must be made accessible: add
role="dialog" and aria-modal="true" on the dialog container and give the title
an id (e.g., id on the h2) and set aria-labelledby to that id; when
showCreateModal/showDeleteModal opens, move initial focus into the dialog (e.g.,
focus the first interactive element like input#link-name or the primary confirm
button) and trap focus inside until closed; add an Escape key handler to close
the modal (set showCreateModal=false / showDeleteModal=false) and restore focus
to the element that opened the dialog; also ensure the background content is
hidden from assistive tech (e.g., set aria-hidden on the main app container or
use inert) while the modal is open.

app/pages/dashboard/ai-analysis.vue (1)

189-283: Consider extracting a reusable stat-card component to reduce duplication.

The five cards share nearly identical structure/classes with only small differences (icon, accent color, value, subtitle). A shared component would make future visual/system changes safer and faster.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/ai-analysis.vue` around lines 189 - 283, The dashboard
has five near-identical stat card blocks; extract a reusable StatCard component
and replace the repeated markup in ai-analysis.vue with it. Create a StatCard
that accepts props like title (e.g., "Total Runs"), value (or a value slot),
icon component, accent classes (for gradient/hover color), small
subtitle/description, and an optional footer slot for conditional content (used
for the pricing block); update usages to pass existing expressions/refs
(formatNumber(summary.totalRuns), successRate, formatCost(totalCost),
summary.completedRuns, summary.failedRuns, pricing.configured, etc.) and
preserve current class/transition behavior by moving conditional :class logic
into props. Ensure the new component exposes the same DOM structure so utilities
like group-hover and absolute icons continue to work.

tests/unit/candidate-timeline.test.ts (1)

8-128: This suite is mostly testing cloned logic, not the feature itself.

querySchema, the timeline helper functions, and the lazy-load/reset behavior are recreated inside the spec instead of imported or exercised through the actual endpoint/component code. A regression in server/api/activity-log/candidate-timeline.get.ts, app/components/CandidateDetailSidebar.vue, or app/pages/dashboard/jobs/[id]/index.vue can therefore leave this file green. Please extract shared schema/helpers into an importable module, or mount the real component/composable and drive the actual watchers.

Also applies to: 259-345

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/unit/candidate-timeline.test.ts` around lines 8 - 128, The test
recreates core logic locally (querySchema, getTimelineActionColor,
describeTimelineItem, makeEntry) instead of importing the canonical
implementations, so extract the shared schema/helpers into a single exportable
module (or import the existing implementations from
server/api/activity-log/candidate-timeline.get.ts and
app/components/CandidateDetailSidebar.vue) and update the test to import
querySchema, getTimelineActionColor, describeTimelineItem and makeEntry from
that module; alternatively, replace the unit-level recreation by mounting the
real component/composable (e.g., CandidateDetailSidebar or the
candidate-timeline composable) in the test and exercising its watchers/endpoint
calls so the spec drives the actual code paths rather than cloned logic.

app/pages/dashboard/jobs/new.vue (1)

1553-1746: Consider rendering the three distribution groups from one shared template/component.

The card body is duplicated almost verbatim for job_board, outreach, and social. Any behavior or copy change now has to be kept in sync in three places. Grouping distributionChannels by category and rendering one reusable section/card would make this flow much cheaper to maintain.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/jobs/new.vue` around lines 1553 - 1746, The template
duplicates the same card markup for each category; refactor by grouping
distributionChannels by category and rendering a single reusable component
(e.g., ChannelGroup) or template that accepts props: channels (array),
createdLinks, createChannelLink, copyChannelLink, channelIcons, and defaultIcon
(Globe). Replace the three v-for blocks that filter by c.category ===
'job_board'/'outreach'/'social' with a single loop over
Object.entries(groupedChannels) (or an array of categories) that renders
<ChannelGroup :channels="channels" :created-links="createdLinks"
:channel-icons="channelIcons" `@create`="createChannelLink"
`@copy`="copyChannelLink" />, and move the duplicated UI (input, buttons, loading
states, classes and checks for createdLinks[ch.channel]?.code/copied/loading)
into that component/template so behavior remains identical while removing
repetition.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/pages/dashboard/jobs/[id]/index.vue (1)

455-490: ⚠️ Potential issue | 🟠 Major

Keep timeline state keyed to the requested candidate.

This still has the stale-response bug from the earlier review: resolvedCurrentApplication can point at the previous candidate while the next detail request is in flight, so loadTimeline() can fetch and commit the wrong history. After that, timelineLoaded flips to true and prevents the actual candidate from loading. Base timelineCandidateId on the currently loaded application only, and ignore any response whose candidate/request id no longer matches before assigning timelineItems.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/pages/dashboard/jobs/`[id]/index.vue around lines 455 - 490, The timeline
fetch can commit stale results because resolvedCurrentApplication may change
while a request is in flight; update loadTimeline and timelineCandidateId to key
state to the requested candidate by capturing the candidate id at request start
(e.g., const requestedId = resolvedCurrentApplication.value?.candidate?.id) and
returning early if missing, then after the $fetch completes verify that
resolvedCurrentApplication.value?.candidate?.id === requestedId before assigning
timelineItems, timelineLoaded, timelineError or timelineLoading; also ensure
timelineCandidateId is computed from the currently loaded application state only
and that any watcher (watch([detailTab, timelineCandidateId], ...)) uses that
keyed id to decide to call loadTimeline so stale responses are ignored.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes